Skip to content

feat: migrate build system from Makefile to CMake#21

Merged
andeplane merged 3 commits intomasterfrom
feat/cmake-build-migration
Mar 30, 2026
Merged

feat: migrate build system from Makefile to CMake#21
andeplane merged 3 commits intomasterfrom
feat/cmake-build-migration

Conversation

@andeplane
Copy link
Copy Markdown
Collaborator

@andeplane andeplane commented Dec 18, 2025

Summary

This PR migrates the build system from the old Makefile-based approach to a modern CMake-based build system, matching the approach used in atomify-main.

Closes #15

Changes

  • Replaced cpp/build.py with CMake-based version that:

    • Uses emcmake cmake to configure LAMMPS with Emscripten
    • Leverages LAMMPS's native CMake build system
    • Supports configurable packages via PACKAGES env var (default: MOLECULE)
    • Supports SINGLE_FILE mode to embed WASM in JS (default: enabled)
    • Supports debug builds with --debug flag
    • Supports force recompilation with --recompile flag
  • Removed cpp/Makefile - no longer needed since CMake handles compilation

  • Updated GitHub workflows to set EMSDK_PATH environment variable required by the new build script

Benefits

  • Better dependency management (CMake handles Voro++, COLVARS, etc. automatically)
  • Cleaner build orchestration
  • Consistent with modern LAMMPS build practices
  • Easier to extend with additional packages

Testing

  • ✅ Build completes successfully locally
  • ✅ All 9 existing tests pass
  • ✅ Output file cpp/lammps.js generated correctly (10MB with embedded WASM)

Usage

# Basic build (requires EMSDK_PATH env var)
EMSDK_PATH=/path/to/emsdk python3 cpp/build.py

# With additional packages
PACKAGES="MOLECULE KSPACE" python3 cpp/build.py

# Debug build with source maps
python3 cpp/build.py --debug

# Force full recompilation
python3 cpp/build.py --recompile


# Configuration
LAMMPS_TAG = os.environ.get("LAMMPS_TAG", "patch_10Sep2025")
PACKAGES = os.environ.get("PACKAGES", "MOLECULE").split()
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should consider maybe deploying multiple versions with different set of packages. Not sure exactly how we should do it though.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense!

@alexjilkin
Copy link
Copy Markdown
Collaborator

Looks good! important improvements.

It means that now if I'm trying to use the build:wasm install script, then a EMSDK_PATH="<some_path>/emsdk" npm run build:wasm is necessary, right?

Otherwise, tested, works well on my machine and the threejs examples continues work.

@andeplane
Copy link
Copy Markdown
Collaborator Author

Looks good! important improvements.

It means that now if I'm trying to use the build:wasm install script, then a EMSDK_PATH="<some_path>/emsdk" npm run build:wasm is necessary, right?

Otherwise, tested, works well on my machine and the threejs examples continues work.

Right, yes. Maybe we don't want that and want to have sourced emscripten first and just use global ref to binaries?

@andeplane andeplane marked this pull request as ready for review December 22, 2025 06:35
@alexjilkin
Copy link
Copy Markdown
Collaborator

Looks good! important improvements.
It means that now if I'm trying to use the build:wasm install script, then a EMSDK_PATH="<some_path>/emsdk" npm run build:wasm is necessary, right?
Otherwise, tested, works well on my machine and the threejs examples continues work.

Right, yes. Maybe we don't want that and want to have sourced emscripten first and just use global ref to binaries?

Looks good! important improvements.
It means that now if I'm trying to use the build:wasm install script, then a EMSDK_PATH="<some_path>/emsdk" npm run build:wasm is necessary, right?
Otherwise, tested, works well on my machine and the threejs examples continues work.

Right, yes. Maybe we don't want that and want to have sourced emscripten first and just use global ref to binaries?

So you mean that the developer will first source it independently, and the project expects to have it as a global ref? I think it's a fine solution. But I also think that having this export param is OK for now.

andeplane and others added 2 commits March 30, 2026 09:28
- Replace cpp/build.py with CMake-based build system
- Remove obsolete cpp/Makefile (CMake handles compilation now)
- Update GitHub workflows to set EMSDK_PATH environment variable
- Build now uses emcmake cmake to configure LAMMPS with Emscripten
- Supports configurable packages via PACKAGES env var (default: MOLECULE)
- Supports SINGLE_FILE mode to embed WASM in JS (default: enabled)
- Supports debug builds with --debug flag
- Supports force recompilation with --recompile flag

This modernizes the build system to match the approach used in atomify-main,
providing better dependency management and cleaner build orchestration.
The CMake migration changed the output path from dist/cpp/lammps.js to
cpp/lammps.js, breaking the test runner which resolves imports from
dist/client.js → dist/cpp/lammps.js.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@andeplane andeplane force-pushed the feat/cmake-build-migration branch from e82f9d6 to a79951b Compare March 30, 2026 07:28
lammpsweb.cpp includes fix_js_async.h, but fix_js_async was missing from
CUSTOM_BASENAMES so it was never copied to the LAMMPS src directory during
the CMake build, causing a fatal compile error.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@andeplane andeplane merged commit 75ac99c into master Mar 30, 2026
1 check passed
@andeplane andeplane deleted the feat/cmake-build-migration branch March 30, 2026 10:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Convert build system to use CMake

2 participants